Some financial transaction instruments, such as credit cards and loyalty program cards, are capable of accessing information related to multiple accounts. For example, a credit card may be able to access membership data associated with both a credit card account and a wholesale purchase club account. These financial transaction instruments may generally include one or more applications for selecting and then securely utilizing a sub-set of specified account information. However, the systems associated with these cards typically delegate the loading of these applications and management of the related data sets to third parties on behalf of both the issuer of the instrument and “application tenants” residing on the issuer's financial transaction instruments. Managing data associated with a credit card via the issuer/third party may involve time consuming steps such as requesting permission to manage data, conforming to data standard formats, and implementing changes. Thus, traditional solutions for managing multiple application tenants are disadvantageous in that the traditional solutions leave a disproportional burden on the issuer and/or the delegated third party in terms of managing accounts on a financial transaction instrument.
Another disadvantage is that, in general, the financial transaction instruments, which are capable of accessing information related to multiple accounts, are typically designed to access only those multiple accounts managed by the same issuer. For example, the same issuer provides both the credit card and the wholesale purchase club account to the user. As such, the issuer providing both accounts generally establishes its own application tenant storage format and management protocol related to the accounts. The established format and protocol is ordinarily different from any format or protocol used by other unrelated issuers, which provides the issuer increased control over access to the account data. Because of the differing unique protocols/formats amongst issuers, multiple issuers typically provide a transaction instrument corresponding to an account offered by the issuer, where the data for accessing the account is stored in that issuer's protocol/format. Thus, a user wishing to access multiple accounts managed by different issuers, must ordinarily carry at least one transaction instrument per issuer. Carrying multiple transaction instruments can be inconvenient in that the instruments may be more easily misplaced, lost or stolen, preventing the user from accessing the account.
Another disadvantage of the above conventional methods of managing multiple accounts, which is related to the different issuer formats/protocols, is that, since conventional financial transaction instruments typically only store application tenant information related to one issuer, the information may not be recognized by a second issuer distinct from the first. That is, the user of the financial transaction instrument typically is only able to use the financial transaction instrument at locations identified by the issuer of the transaction card. The financial transaction instrument may not be used at any other locations, since the locations not identified by the user will not recognize the application tenant information which is typically stored on the instrument in a issuer determined format. As such, in order to access multiple accounts managed by different issuers using different formats/protocols, the user must typically carry multiple cards, as noted above.
In addition to the above, the conventional multiple account management systems have another disadvantage in that data contained on the financial transaction instruments may not be easily updated. That is, traditional financial transaction instruments are only “readable” instruments, and not “writeable” instruments, where the data on the instrument may be read from the instrument but not written to the instrument. More particularly, once the financial instrument is issued to the user, the data often may not be modified. Instead, where information contained on the instrument is to be modified, a new physical consumer device (e.g., transaction instrument) often needs to be issued. That is, the information stored on the financial transaction instruments are typically not permitted to be changed without issuer involvement. The issuer may be involved, for example, by verifying compatibility of a proposed new or updated information, checking conformance of the data to the issuer's standard formatting and size guidelines, and implementing the changes. Thus, additional burdens are placed on the issuer where it is necessary to add unique data sets to a financial transaction instrument, or to update the data stored thereon.
As such, the ability to store data on a single financial transaction instrument thereby permitting a user of the single instrument to complete transactions using multiple transaction accounts issued by different distinct issuers, does not exist. A need exists for a single financial transaction instrument which stores multiple independent data sets provided by multiple distinct issuers irrespective of the format/protocol of the various issuers. A need further exists for a single financial transaction instrument which may be used to efficiently manage the data sets and applications stored on the instrument, irrespective of the protocol used by an issuer to process the data. Even more particularly, a need exists for a system for managing multiple transaction accounts of differing formats on a single financial transaction instrument which is issued to a user, and which permits the user to access different accounts provided by multiple distinct financial account issuers.